在互联网领域，高性能、高并发、高可用相关的讨论屡见不鲜，三高问题中高性能和高并发大家工作中接触较多，对于高可用，往往是纸上谈兵。前几年提到高可用，什么同城容灾架构、异地容灾架构、两地三中心方案层出不穷，坊间还充斥着支付宝CTO剪网线、饿了么CTO主动做IDC断网测试等各种段子，美团在2019年也组织过GQ、YF机房整体断网演练。前几年业界内没有发生大规模的机房级别故障，我也会怀疑是否有必要投入高昂的成本来建设机房容灾能力。然而最近两年，先后出现亚马逊机房故障、美团0704故障到最近的阿里云香港机房故障，这些故障也印证了墨菲定律：如果事情有变坏的可能，不管这种可能性有多小，那么它总会发生。

ZK，全称为 ZooKeeper，是一个分布式协调服务，由雅虎公司开发并开源。ZK 提供了一个高可用、高性能（Raptor测试链接同机房直连ZK节点Avg耗时0.1ms）、分布式的协调服务，用于解决分布式系统中的一些协调问题，如分布式锁、分布式协调、分布式配置中心、分布式队列等。被广泛地应用于诸如 Hadoop、HBase、Kafka 和 Dubbo 等大型开源分布式系统中。

ZK整体构成包括Leader、Follower、Observer以及客户端，其中Leader、Follower参与Leader竞选，并负责对于写请求进行投票。由于每次写请求，Leader都必须和所有Follower基于类似两阶段提交协议来决定写入是否成功，所以Follower节点不能过多。同时为了提高集群整体的读性能，进而引入了Observer节点。下图描述了从客户端发起一次请求到服务端响应的整个过程（假设客户端此时连接的是Follower节点，相比于连接Leader处理过程更为复杂）

最近一段时间，一到业务午高峰，外卖集群的一些订阅机器就会出现Binlog消费大量延时。出现Binlog延时的原因主要是：一般11点开始，外卖业务进入中午午高峰，数据库的Binlog QPS会逐渐增加，一旦订阅服务出现性能瓶颈，处理Binlog的能力跟不上Binlog生成的速度，就会导致消费Binlog出现延时，并且延时时间会越来越长。业务在BCP上配置的核对规则一般最小是60s，一旦Binlog延时时间超过60s，那么规则就会大量误告。

本文首先会介绍在Mac上如何通过docker来安装es单机版本和集群版本，然后重点叙述如何使用IDEA编译Elasticsearch源码并进行调试

业务经常会使用消息中间件进行上下游解耦或者异步削峰填谷的目的，通常处理流程是如下：操作本地数据库，完成自身业务逻辑